Communications networks, including without limitation wide area networks (“WANs”) and local area networks (“LANs”), may be implemented as a set of interconnected switches that connect a variety of network-connected nodes to communicate data and/or control packets among the nodes and switches. Various networking protocols may be employed to allow different devices to communicate across and within the network. However, it can be a challenge to provide interoperability between networks and devices operating under different protocols.
One technique for providing such interoperability is called Multiprotocol Label Switching (MPLS), which establishes efficient endpoint-to-endpoint transportation of data over connectionless networks. MPLS is described in detail by Rosen et al., in Requests for Comments (RFC) 3031 of the Internet Engineering Task Force (IETF), entitled “Multiprotocol Label Switching Architecture” (January 2001), which is incorporated herein by reference for all that it discloses and teaches. In MPLS, each packet is assigned to a Forwarding Equivalence Class (FEC) when it enters the network. The FEC is assigned based on the packet's destination address. A packet receives a short, fixed-length label identifying the FEC to which it belongs. All packets in a given FEC are passed through the network over the same path by label-switching routers (LSRs), which simply use the label as an index to a look-up table. The table specifies the next hop on the packet's path for an individual FEC and the label that the LSR attaches to the packet for the next hop. In this manner, the packet is conveyed through the network based on its label field.
Each flow of packets along a virtual circuit (VC) under MPLS is completely specified by the label applied at the ingress node of the network path. A VC represents a tunnel through the network, such as between two provider edge (PE) routers. MPLS tunnels are established by “binding” a particular label, assigned at the ingress node of the network, to a particular FEC. Multiple tunnels may belong to the same FEC, but each tunnel will have its own label binding. One or more ports of each PE router can act as endpoints of the tunnel and connect to customer edge (CE) devices, such as a customer-operated switch or server.
An endpoint-to-endpoint communication through a tunnel can be configured as a virtual leased line (VLL) service to carry bandwidth-guaranteed applications, such as voice, video, and online transaction processing, through the network. In the case of a local-VLL service (at specific type of VLL service), both endpoints can reside on the same router. In such cases, the entire local VLL resides within the router.
In one implementation, a VLL service uses a VC in the tunnel to provide bidirectional communications, and each VLL service is given a unique identifier (ID), called a VLL ID, which is also referred to as a virtual connection ID (VCID). Each router at an end of the VLL service is configured with the VLL ID and the address of the other router of the VLL service, which is called a VLL peer. If a VLL service is improperly configured, then data will not flow properly across the VC (e.g., the VLL modes of the routers do not match) or the network will present confusing information (e.g., a VLL name mismatch between two endpoints of the VLL). Other conflicts may also occur. However, it is difficult to troubleshoot such problems because such conflicts are not easily identified using previous approaches, particularly in large networks.
Furthermore, whereas a VLL service provides an endpoint-to-endpoint tunnel in label switched services, a Virtual Private LAN Segment (VPLS) service provides full mesh connectivity using label switched services. For example, in a network including four provider-edge (PE) routers, a VC is established between each pair of PE routers, resulting in 6 VCs. Each CE device connected to one of the PE routers communicates as though it resides in the same subnet as the other CE devices, regardless of their physical topology. However, configuration conflicts in a VPLS service are also difficult to troubleshoot because such conflicts are not easily identified using previous approaches, particularly in large networks